SQL Server 2008: Security and User Administration - Managing Principals (part 2) - Roles

Roles

Roles provide a consistent yet flexible model for security administration. Roles are similar to the groups used in administering networks. Permissions are applied to a role, and then members are added to the role. Any member of the role has all the permissions that the role has.

The use of roles simplifies the administrative work related to security. Roles can be created based on job function, application, or any other logical group of users. With roles, you do not have to apply security to each individual user. Any required changes to permissions for the role can be made to the role security, and the members of the role receive those changes.

SQL Server has the following three types of roles:

• Fixed server and fixed database roles— These roles are installed by default and have a predefined set of permissions.

• User-defined roles— These roles are created in each database, with a custom set of permissions for each set of users assigned to it.

• Application roles— These special roles can be used to manage database access for an application.

These roles are discussed in the following sections.

Fixed Server Roles

Fixed server roles are scoped at the server level, which means that the permissions for these roles are oriented toward server-level securables. These roles contain a variety of fixed permissions geared toward common administrative tasks. Logins (not users) are assigned to these roles.

The same fixed server roles available in SQL Server 2000 and SQL Server 2005 are also available in SQL Server 2008. There is, however, one new role named public that has been added. Server principals, by default, are granted the permissions that have been granted to the public role. There are a limited number of permissions that are initially granted to the public role, but you can change the permissions if you like. A complete list of all the fixed server roles and their related permissions is shown in Table 1.

A single login can be assigned to one or more of these fixed server roles. When multiple roles are assigned, the combination of all the permissions is allocated to the login.

All the fixed server roles are listed in the SQL Server Management Studio (SSMS) Object Explorer. Figure 1 shows the Object Explorer with the Server Roles node expanded. You can right-click any of the roles and select Properties to display the logins that are currently members of the role.

Fixed Database Roles

SQL Server provides fixed roles that define a common set of permissions at the database level. These fixed database roles are assigned to database users. The permissions defined for the fixed database roles cannot be changed. Table 2 shows the fixed database roles and their permissions.

You can also find a list of fixed database roles in the Object Explorer. Figure 2 shows the fixed database roles for the AdventureWorks2008 database. The roles are found under the Security node within each database. You can right-click a fixed database role and select Properties to view the member users.

Fixed database roles and schemas are related. Figure 11.3 shows the expanded Schemas node for the AdventureWorks2008 database. You can see that there is a corresponding schema for each of the fixed database roles. These schemas are automatically created, and each is owned by the related database role.

The public Role

The public role is a special database role that is like a fixed database role except that its permissions are not fixed. The permissions for this role can be altered. Every user in a database is automatically made a member of the public role and in turn receives any permissions that have been granted to the public role. Database users cannot be removed from the public role.

The public role is similar in function to the guest user that is installed by default in each database. The difference is that the permissions granted to the guest user are used by any login that does not have a user account in the database. In this case, the login is allowed to enter the database via the guest account. In the case of the public role, the login has been added as a user of the database and in turn picks up any permissions that have been granted to the public role.

To view the permissions associated with the public role, you can use a SELECT statement like the following:

SELECT top 5 g.name,
    object_name(major_id) as 'Object',
    permission_name
 from sys.database_permissions p
 join sys.database_principals g
  on p.grantee_principal_id = g.principal_id
    and g.name = 'public'
order by 1,2

/*Results from the previous select
name    Object          permission_name
------  --------------  ---------------
public  all_columns     SELECT
public  all_objects     SELECT
public  all_parameters  SELECT
public  all_sql_modules SELECT
public  all_views       SELECT
*/

This SELECT utilizes two catalog views that contain security information. The SELECT returns only the first five permissions for the public role, but the TOP clause can be removed to return all the permissions.

User-Defined Roles

SQL Server enables you to create your own custom database roles. Like the fixed roles, user-defined roles can be used to provide a common set of permissions to a group of users. The key benefit behind using user-defined roles is that you can define your own set of custom permissions that fit your needs. User-defined roles can have a broad range of permissions, including the more granular set of permissions made available with SQL Server 2008.

To demonstrate the power of a user-defined database role, let’s look at a simple example. Let’s say that you have a group of users who need to read all the tables in a database but should be granted access to update only one table. If you look to the fixed database roles, you have the db_datareader and db_datawriter roles, which give you a partial solution. You can use the db_datareader role to allow the read capability you need, but the db_datawriter role gives write permission to all the tables—not just one.

One possible solution would be to give every user in the group membership to the db_datareader group and assign the specific UPDATE permission to each user as well. If the group contains hundreds of users, you can see that this would be rather tedious. Another solution might be to create a Windows group that contains every user who needs the permissions. You can then assign a login and database user to this group and grant the appropriate permissions. The Windows group is a viable solution but can sometimes be difficult to implement in a complex Windows domain.

Another approach to this challenge is to use a user-defined database role. You can create the role in the database that contains the tables in question. After you create the role, you can include it in the db_datareader role, and you can establish the UPDATE permission to the single table. Finally, you can assign the individual users or group of users to the role. Any future permission changes for this set of users can be administered through the user-defined database role. The script in Listing 1 testuser. steps through a process that demonstrates and tests the addition of a database role. This is similar to the example we just walked through. Parts of the script need to be run by an administrator, and other parts should be run in a query editor window that is connected to the database with the newly created

Listing 1. An Example of User-Defined Database Roles

--The following statements must be run by an administrator to add
--a login and database user with no explicit permissions granted
CREATE LOGIN [TestUser] WITH PASSWORD=N'pw',
DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

GO
USE [AdventureWorks2008]
GO
CREATE USER [TestUser] FOR LOGIN [TestUser]
go
--the following statement fails when executed by the TestUser
--which has no explicit permissions defined in the AdventureWorks2008 database
select top 5 * from person.person
UPDATE person.person SET suffix = 'Jr.'
 WHERE FirstName = 'Ken'
--The following statement is run by an administrator to:
--1)add a new TestDbRole with permission to UPDATE
--2)grant UPDATE permission on the Person.person table
--3)add the TestUser to the TestDbRole database role
USE [AdventureWorks2008]
GO
--1)
CREATE ROLE [TestDbRole] AUTHORIZATION [dbo]
--2)
GRANT UPDATE ON [Person].[Person] TO [TestDbRole]
GRANT SELECT ON [Person].[Person] TO [TestDbRole]
--3)
EXEC sp_addrolemember N'TestDbRole', N'TestUser'

--the following statements now succeed when executed
--by the TestUser because the role that it
--was added to has SELECT and UPDATE permission
--on that table
select top 5 * from person.person
UPDATE person.person SET suffix = 'Jr.'
 WHERE ContactID = 1
--the following select fails because 'testdbrole'
--does not permit SELECT on any table but person.person
select * from person.ContactType
--The following statement is run by an administrator
--to add the TestDbRole database role to the db_datareader
--fixed-database role
EXEC sp_addrolemember N'db_datareader', N'TestDbRole'
GO
--Finally, the testuser can update the Person.person table
-- and select from any other table in the database
select * from person.ContactType


					    

Application Roles

Unlike other roles, application roles contain no database users. When an application role is created , rather than add a list of users who belong to the role, you specify a password. To obtain the permissions associated with the role, the connection must set the role and supply the password. This is done using the stored procedure sp_setapprole. You set the role to the sales application role (with the password PassW0rd) as follows:

EXEC sp_setapprole 'sales', 'PassW0rd'

You can also encrypt the password:

EXEC sp_setapprole 'sales', {ENCRYPT N ' PassW0rd'}, 'odbc'

When an application role is set, all permissions from that role apply, and all permissions inherited from roles other than public are suspended until the session is ended.

So why is it called an application role? The answer is in how it is used. An application role is used to provide permissions on objects through an application, and only through the application. Remember that you must use sp_setapprole and provide a password to activate the role; this statement and password are not given to the users; rather, they are embedded in the application’s CONNECT string. This means that the user can get the permissions associated with the role only when running the application. The application can have checks and balances written into it to ensure that the permissions are being used for the forces of good and not evil.